• Testing: No unit tests are included for any of the pure functions (trajectory extraction, report generation, metric parsing). Even for hackathon/prototype code, the regex-heavy trajectory logic would benefit from test coverage.
• Code Hygiene: Unused zod dependency, unused ROOT constant, and .cache/ directory not gitignored.
• Composability: process.exit() calls in library functions make the code harder to test and reuse — throwing errors and handling at the CLI boundary would be more idiomatic.
• Robustness: Timer leak in Promise.race timeout pattern, and no validation of --min-coverage input.

#1 — post-run trajectory extraction vs. in-place mutation

// runner.ts — runs AFTER agent.invoke() completes
const trajectory = extractTrajectory(agent.messages, repoDir)

• SlidingWindowConversationManager → messages.splice(0, trimIndex) (sliding-window-conversation-manager.ts:268) removes oldest messages.
• SummarizingConversationManager → messages.splice(0, messagesToSummarizeCount, summaryMessage) (summarizing-conversation-manager.ts:173) replaces oldest ~30% with a summary.
• ContextOffloader → only edits toolResult content via AfterToolCallEvent; toolUse blocks survive (plugin.ts).

Net: coverage is under-counted for compressing configs and under-counted more the more aggressively they compress — so the comparison is apples-to-oranges. Suggested fix: capture tool calls live with a BeforeToolCallEvent/AfterToolCallEvent hook into a side list, instead of reconstructing from the post-run message array. This is the single highest-impact change.

#2 — regex parser (tested locally against extractFilePathsFromToolCall)

The -n flag is captured as the path then dropped by the startsWith('-') guard, so the file is silently lost. Suggested fix: strip flags (-n, -50, +100) before treating tokens as paths, handle multiple files per command, and capture grep/rg/find targets — or better, have the agent read through a structured tool you can parse reliably rather than reverse-engineering bash.

#3 — always-zero metrics

runner.ts calls evaluate(task, fileList) with no spans, and evaluator.ts hardcodes spans: spans ?? {}, symbols: {}, so symbol/span/editloc are always 0. The reporter.ts table and README still list them as real metrics. Suggested fix: either populate spans/symbols (the TrajectoryEntry already has startLine/endLine fields) or drop those rows from the report + README until they're wired up.

4. BedrockModel({ modelId, stream: false }) doesn't set temperature, and each config runs once on a single task. Run-to-run sampling variance will look like config differences (especially in CloudWatch trends). Consider temperature: 0, and ideally multiple seeds/tasks with reported variance — otherwise a 5–10% swing is within noise.

5. toRelativePath doesn't strip ./ or resolve relative paths, so ./foo.py or a bare path after cd won't match gold foo.py — counts as both a miss and a false positive. Normalize to repo-relative POSIX paths before comparing.

• 6. runner.ts clears timeoutId on the success path but not in the catch, leaving the 10-min timer pending on errors (also flagged by the bot).
• 7. CloudWatch TokenUsage = input+output, but the README/reporter frame "Input Tokens" as the cost proxy — pick one definition so trend lines stay consistent.
• 8. git checkout A || git fetch && git checkout A parses as (checkout || fetch) && checkout, so the happy path checks out twice. Harmless, just wasteful.